- for [[hazard analysis]]
- by [[nancy leveson]] and [[john thomas]]
- [[pull]] [[stpa handbook]] [[stpa workshop]]
-
[[push]] [[stpa]]
- i love how STPA defers key steps to a later stage so they can be done systemically, once partial but complete initial modeling has taken place.
- it can be applied recursively. it could be argued that because STPA can be applied recursively the cost of abstraction is minimized or at least bound.
-
4 [[steps]]
-
- define the purpose of the analysis, including [[losses]], [[scope]], [[hazards]], [[constraints]] (optionally derived also from [[sub hazards]]).
-
- model the control structure
-
- identify unsafe control actions
-
- identify loss scenarios
-
-
step one: [[define the purpose of the analysis]]
- start with the [[losses]], which involve something of value to stakeholders
- continue by defining the [[scope]] of the system
-
find [[hazards]], which are systemic states or conditions to be prevented, and which together with (worst-case) environmental conditions lead to [[losses]].
- [[hazards]] + [[environmental conditions]] -> [[losses]]
-
find [[system level constraints]].
- they can look like [[hazards]], inverted.
- or define how the system must [[minimize losses]] in case the hazards occur.
- optionally find [[sub hazards]], which might also help define further constraints
-
step two: [[model the control structure]]
-
a control structure is a system model that is composed of feedback control loops.
- a good control structure will enforce the system level constraints.
-
control goes down, feedback goes up
- vertical axis represents a hierarchy ([[heterarchy]]? perhaps in voting systems)
- [[responsibilities]] can be assigned to each control structure entity; they are refinements of [[system level constraints]]
- [[feedback]] can be derived from [[responsibilities]] (which information does the process model need to contain?)
-
step three: [[identify unsafe control actions]]
- an [[unsafe control action]] is one that, in a particular context, will lead to a [[hazard]].
- it must include the actual (real) context in which the control action is unsafe, instead of controller beliefs; and it must be linked to a hazard.
- define [[controller constraints]]: behaviours that need to be satisfied to prevent UCAs. they can usually be derived from negations of the UCAs.
-
step four: [[identify loss scenarios]]
- a [[loss scenario]] describes the [[causal factors]] that can lead to the [[unsafe control actions]] and to [[hazards]].
- 4a: write scenarios which cause UCAs
- 4b: write scenarios where control actions are ont followed